In all aspects of computing, the level of sophistication in displaying information is rising quickly. Information once delivered as simple text is now presented in visually pleasing graphics. Where once still images sufficed, full motion video, computer-generated or recorded from life, proliferates. As more sources of video information become available, developers are enticed by opportunities for merging multiple video streams. (Note that in the present application, “video” encompasses both moving and static graphics information.) A single display screen may concurrently present the output of several video sources, and those outputs may interact with each other, as when a running text banner overlays a film clip.
Presenting this wealth of visual information, however, comes at a high cost in the consumption of computing resources, a problem exacerbated both by the multiplying number of video sources and by the number of distinct display presentation formats. A video source usually produces video by drawing still frames and presenting them to its host device to be displayed in rapid succession. The computing resources required by some applications, such as an interactive game, to produce just one frame may be significant, the resources required to produce sixty or more such frames every second can be staggering. When multiple video sources are running on the same host device, resource demand is heightened not only because each video source must be given its appropriate share of the resources, but because even more resources may be required by applications or by the host's operating system to smoothly merge the outputs of the sources. In addition, video sources may use different display formats, and the host may have to convert display information into a format compatible with the host's display.
Traditional ways of approaching the problem of expanding demand for display resources fall along a broad spectrum from carefully optimizing the video source to its host's environment to almost totally ignoring the specifics of the host. Some video sources carefully shepherd their use of resources by being optimized for a specific video task. These sources include, for example, interactive games and fixed function hardware devices such as digital versatile disk (DVD) players. Custom hardware often allows a video source to deliver its frames at the optimum time and rate as specified by the host device. Pipelined buffering of future display frames is one example of how this is carried out. Unfortunately, optimization leads to limitations in the specific types of display information that a source can provide: in general, a hardware-optimized DVD player can only produce MPEG2 video based on information read from a DVD. Considering these video sources from the inside, optimization prevents them from flexibly incorporating into their output streams display information from another source, such as a digital camera or an Internet streaming content site. Considering the optimized video sources from the outside, their specific requirements prevent their output from being easily incorporated by another application into a unified display.
At the other end of the optimization spectrum, many applications produce their video output more or less in complete ignorance of the features and limitations of their host device. Traditionally, these applications trust the quality of their output to the assumption that their host will provide “low latency,” that is, that the host will deliver their frames to the display screen within a short time after the frames are received from the application. While low latency can usually be provided by a lightly loaded graphics system, systems struggle as video applications multiply and as demands for intensive display processing increase. In such circumstances, these applications can be horribly wasteful of their host's resources. For example, a given display screen presents frames at a fixed rate (called the “refresh rate”), but these applications are often ignorant of the refresh rate of their host's screen, and so they tend to produce more frames than are necessary. These “extra” frames are never presented to the host's display screen although their production consumes valuable resources. Some applications try to accommodate themselves to the specifics of their host-provided environment by incorporating a timer that roughly tracks the host display's refresh rate. With this, the application tries to produce no extra frames, only drawing one frame each time the timer fires. This approach is not perfect, however, because it is difficult or impossible to synchronize the timer with the actual display refresh rate. Furthermore, timers cannot account for drift if a display refresh takes slightly more or less time than anticipated. Regardless of its cause, a timer imperfection can lead to the production of an extra frame or, worse, a “skipped” frame when a frame has not been fully composed by the time for its display.
As another wasteful consequence of an application's ignorance of its environment, an application may continue to produce frames even though its output is completely occluded on the host's display screen by the output of other applications. Just like the “extra” frames described above, these occluded frames are never seen but consume valuable resources in their production.
What is needed is a way to allow applications to intelligently use display resources of their host device without tying themselves too closely to operational particulars of that host.